I had to let this sit a bit longer to gain clarity, and also life got in the way for quite a while. However, I think I've narrowed this down to a sensible implementation and I think its ready for more eyes.

@pascalkuthe certainly! Perhaps the best way to explain is to look at some specific examples that don't fit the mold precisely.

In JavaScript, there are a number of ways to create objects. One of these is the "object literal" syntax, which looks a lot like a hash table definition in other languages:

const person = {
  name: 'Ragesh',
  age: '52',
};

In this instance, it is easy to say that the person object represents a data structure, where the key-value pairs form our textobject's subject. However, consider also that JavaScript has first-class functions, allowing us to construct an object with a more traditional class-oriented shape:

const person = {
  name: 'Yvette',
  age: '33',
  speak: () => console.log('Bonjour!')
}

Here the speak member is an invokable function, veritably a method. I chose not to try to distinguish this type of member as it makes the queries much more difficult to write (and probably less performant). So methods on an object in this form get to be recognized as "entries in a data structure-like thing".

Now consider that in recent years JavaScript grew some class-based syntactic sugar to make constructing objects more familiar to those coming from class-based OO languages. We now can express the same object this way:

class Person {
  constructor(name, age) {
    this.name = name
    this.age = age
  }

  speak() {
    console.log('你好')
  }
}

const person = new Person('Jian', 19)

Does it now make sense to be able to jump to the assigments for this.name and this.age? Should the speak method be considered an entry/element here too? Or private members like this?

class Fish {
  #numFins = 3
  getNumFins() {
    return this.#numFins
  }
}

Initially, my answer was "yes, these should count", but as I tried it in more contexts it just felt kind of inconsistent and awkward to use. Even where you might expect it to act like entries in a data structure there can be awkwardness, for example with a PHP Data Transfer Object pattern:

readonly class BlogData
{
    public function __construct(
        public string $title,
        public Status $status,
        public ?DateTimeImmutable $publishedAt = null,
    ) {}
}

Here you can see that due to PHP's constructor property promotion (adding visibility to the constructor signature means those arguments immediately become properties on that class with said visibility), we now have an overlap between the definition of the "argument/parameter" textobject we already have and this new "entry/element" textobject.

In the specific case of Rust, field definitions on a struct feel to me like they belong, as structs are often thought of as data structures more consistently, and the fact that method impls are separated into their own impl block separated from the definition of the fields makes the kind of awkwardness I show above less bothersome in practice. I am open to backing off of that as well though.

In other words, getting a useful definition of what does and does not belong is difficult to achieve. I gave it my best shot for the covered languages, given that my experience with many of them is surface level.

That makes sense to me. I guess you could in theory view every assignment as a key value pair which I definitely wouldn't want the captures to do.

Rust is fairly rigorous and I think I agree with the way its defined there and python makes sense too. I don't have enough experience with js/php to really comment on that but your explanation sounds reasonable.